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Appl. No. 09/314,615 

Reply to Final Office Action of March 7, 2005 

REMARKS/ARGUMENTS 

Reconsideration of the rejections set forth in the Final Office Action dated March 7, 2005 
is respectfully requested. Claims 1-28 are currently pending and have been rejected. 

Specification 

It is not entirely clear to the Applicant why the Examiner is "reminding" the Applicant of 
the proper content of an abstract of the disclosure. On page 2 of the Final Office Action, the 
Examiner has italicized the statement that reads "The abstract should not refer to purported 
merits or speculative applications of the invention and should not compare the invention with the 
prior art." 

Although the Examiner does not appear to have specifically objected to the disclosure, 
and has not set forth the passages of the disclosure to which he apparently takes exception, the 
Applicant has amended the abstract in a sincere effort to address the Examiner's apparent 
concerns. Specifically, the Applicant has removed the last sentence of the abstract, and has 
amended the abstract to recite a method of dynamically loading protocol stacks. It is noted that 
the amendments made to the abstract are based upon the subject matter claimed in claim 1 . As 
such, it is respectfiilly submitted that there is no new matter added by way of these amendments. 

Rejections under 35 U.S.C. S 102 and 35 U.S.C. 6 103 

Claims 1-3, 7-10, 12, 14-18, 22-25, and 27 have been rejected under 35 U.S.C. § 102(b) 
as being anticipated by U.S. Patent No. 5,640,394, issued June 17, 1997 to Schrier et aL 
(hereinafter "Schrier"). Claims 1 1, 13, 26, and 28 have been rejected under 35 U.S,C. § 103(a) 
as being unpatentable over Schrier. Claims 4-6 and 19-21 have been rejected under 35 U.S.C. § 
1 03(a) as being unpatentable over Schrier in view of U.S. Patent No. 6,032,154, issued February 
29, 2000 to Coleman et aL (hereinafter "Coleman"). 
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L Independent Claims 7, 10, 12, and their respective dependents 

Independent claim 1 recites a method which includes receiving a message to load a first 
protocol stack, and determining whether the first protocol stack can be loaded. If the first 
protocol stack cannot be initially loaded, then the second protocol stack is unloaded. After the 
second protocol stack is unloaded,, the first protocol stack is loaded 

On page 9 of the Final Office action dated March 7, 2005, the Examiner has stated that 
the Applicant admits that Schrier teaches a method of operating two protocol stacks that 
implement the same protocol, and that claim 1 does not specify implementing different protocols. 
The Applicant concurs with the Examiner's statements, but note that it has never been asserted 
by the Applicant that claim 1 somehow specifies implementing different protocols. 

The Applicant respectfully disagrees with the Examiner's statement on page 10 of the 
Final Office Action dated March 7 f 2005 which reads "Applicant also asserts that the Schrier 
reference is not able to differentiate between the two loaded protocol stacks. However, the 
reference teaches 'real mode' and 'protected mode 5 protocol stacks," At lines 29-34 of column 
4, Schrier states: 

"As discussed above, once a real mode protocol stack has been loaded 
and is operating, it is not possible to run a subsequent protected mode 
version of a protocol stack which implements the same protocol 
because the stack manager is not able to differentiate between the 
two protocol stacks." [emphasis added] 

It is respectfully submitted that Schrier teaches of not being able to differentiate between two 
protocol stacks (a real mode protocol stack and a protected mode version of the protocol stack). 
A careful reading of the above-recite passage makes it clear that the two protocol stacks that the 
stack manager is unable to differentiate are a real mode protocol stack and a protected mode 
protocol stack. The Examiner has even cited the above-recited passage in his rejection of claim 
1 . Hence, the assertion of the Applicant is based on the direct teachings of Schrier. It is Schrier 
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that makes it clear that a stack manager is not able to differentiate between a real mode protocol 
stack and a protected mode protocol stack. 

Schrier is generally directed to methods of operating two protocol stacks that implement 
the same protocol The reference describes that this situation can occur if the same protocol is 
implemented in one protocol stack in real mode for MS-DOS and one protocol stack for 
protected mode of WINDOWS (Schrier, column 3 at lines 57-63). Schrier describes that a stack 
manager is unable to differentiate which protocol stack to use (Schrier, column 4 at lines 29-34). 
It appears that both protocol stacks of Schrier are loaded, otherwise there would be no issue with 
two protocol stacks that implement the same protocol, ie, Schrier teaches that a first protocol 
stack and a second protocol stack are such that both can be loaded at the same time. 

As taught by Schrier, when a second protocol stack (e.g. , the real mode protocol stack for 
the protocol) is loaded and operating, it is not possible to run a first protocol stack (e.g., the 
protected mode protocol stack for the protocol) because a stack manager cannot differentiate 
between the first and second protocol stacks (Schrier, column 4 at lines 29-34). Schrier teaches 
that a solution would be to terminate the second protocol stack (e.g., the real mode protocol stack 
for the protocol) and transfer communication responsibilities using the second protocol stack to 
the first protocol stack (e.g. , the protected mode protocol stack for the protocol) (Schrier, column 
4 at lines 34-37). Schrier discloses that such a solution is tremendously difficult if not, as a 
practical matter, impossible. 

In the passages cited by the Examiner in the Final Office Action dated March 7, 2005 as 
anticipating claim L Schrier addresses the problem of a stack manager not able to differentiate 
between two loaded protocol stacks. Schrier does not appear to teach of receiving a message to 
load a first protocol stack. Schrier appears to suggest receiving a request to run a protected mode 
version after a real mode is operating, but does not teach or even suggest receiving a message to 
load the first protocol stack . There is also no teaching in Schrier of determining whether the first 
protocol stack can be loaded . As discussed above, Schrier appears to teach that two protocol 
stacks may both be loaded at the same time. The stack manager of Schrier is not able to 
differentiate between two loaded protocol stacks, and, therefore, must transfer communications 
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responsibilities for applications onto a single loaded protocol stack. There is no determination of 
whether a protocol stack can be loaded, as both protocol stacks taught by Schrier are loaded, and 
the issue addressed by Schrier has to do with switching from a real mode of operation (which 
uses a real mode protocol stack) to a protected mode of operation (which uses a protected mode 
protocol stack). 

Schrier teaches, as discussed above, of terminating a second protocol stack and then 
transferring responsibilities of applications using the second protocol stack to a first protocol 
stack when a protected mode version of the first protocol stack is to be run (Schrier, column 4 at 
lines 24-27). It is respectfully submitted that transferring responsibilities of applications to a 
different protocol stack when the different protocol stack is to be run is not the same as, and does 
not suggest, receiving a message to load a first protocol stack, determining whether the first 
protocol stack can be loaded, and unloading the second protocol stack if the first protocol stack 
cannot be initially loaded. Accordingly, claim 1 is believed to be allowable for at least the 
reasons set forth, 

Claims 2-9 each depend either directly or indirectly from claim 1 and are, therefore, each 
believed to be allowable over the cited art for at least the reasons set forth with respect to claim 
1, Each of these dependent claims recites additional limitations which, when considered in light 
of claim 1 9 are believed to further distinguish the claimed invention over cited art By way of 
example, claim 2 recites that a first protocol stack cannot be initially loaded because memory was 
not available to load the first protocol stack. The Examiner has argued, on page 4 of the Final 
Office Action dated March 7, 2005, that Schrier teaches memory conflicts for loading a protocol 
stack. The Applicant respectfully disagrees. In the passages cited by the Examiner, namely 
passages at lines 8-10 and 23-24 of column 4 of Schrier, Schrier merely teaches that programs 
reside in highly specified and crowded areas of conventional memory, and that fewer memory 
conflicts occur in extended or expanded memory. There is no teaching or suggestion of being 
unable to initially load a first protocol stack because memory is not available, as required by 
claim 2. In fact, Schrier does not appear to teach of being unable to load any protocol stack for 
any reason, and makes no mention to memory being unavailable to load a protocol stack. Schrier 
appears only to teach that certain areas of conventional memory are crowded, and that fewer 
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memory conflicts occurs in extended memoTy. Such teaching does not anticipate the limitations 
of claim 2. As such, claim 2 is also believed to be allowable over Schrier for at least this 
additional reason- 
Independent claims 10 and 12 recite similar limitations as recited in claim 1. Therefore, 
claims 10, 12, and their dependents are each believed to be allowable over the cited art for at 
least the reasons set forth above with respect to claim 1. 

2 Independent Claims 14, 25, 27, and their respective dependents 

Independent claim 14 recites a method which includes sending a message from a first 
node to a second node to load a first protocol stack. The method also includes the second node 
receiving the message to load the first protocol stack, the second node determining whether the 
fist protocol stack can be loaded, and the second node unloading a second protocol stack if the 
first protocol stack cannot be initially loaded on the second node. Finally, the method includes 
the second node loading the first protocol stack* 

Claim 14 recites similar limitations as recited in claim 1. As such, claim 14 is believed to 
be allowable over Schrier for at least the reasons set forth above with respect to claim 1 . 

It is noted that while claim 14 may be a '"variation" of claim 1, as stated by the Examiner 
on page 5 of the Final Office Action dated March 7, 2005, claim 14 recites additional limitations 
which are neither taught nor suggested by Schrier. By way of example, claim 14 recites that a 
first node sends a message to a second node to load a first protocol stack. The Applicant 
respectfully submits that there is no teaching in Schrier of first and second nodes, let alone a first 
node that sends a message to a second node to load a first protocol stack. As Schrier does not 
appear to teach the limitation of a first node sending a message to a second node (e.g. , a message 
to load a first protocol stack), claim 14 is believed to be allowable over Schrier for at least this 
reason as well. 
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Claims 15-24 each depend either directly or indirectly from independent claim 14 and 5 
hence, are each believed to be allowable over the cited art for at least the reasons set forth above 
with respect to claim 14. Each of these dependent claims recites additional limitations which, 
when considered in light of the limitations in claim 14, are believed to further distinguish the 
claimed invention over the art of record. For example, claim 15 requires that first and second 
nodes are in different devices. Schrier does not appear to teach of one device sending a message 
to a second device to load a first protocol stack. As Schrier does not appear to teach of nodes 
being in different devices* claim 1 5 is believed to be allowable for this reason as well. 

Independent claims 25 and 27 recite similar limitations as recited in claim 14. Therefore, 
claims 25, 27, and their dependents are all believed to be allowable over the cited art for at least 
the reasons set forth above with respect to claim 14. 

Conclusion 

For at least the foregoing reasons, the Applicant believes all the pending claims are in 
condition for allowance and should be passed to issue. If the Examiner feels that a telephone 
conference would in any way expedite the prosecution of the application, please do not hesitate 
to call the undersigned at (650) 694-5339. 

0 ^,jA^_oS__ 

SIEMENS CORPORATION 
Customer Number: 28524 
Intellectual Property Department 
170 Wood Avenue South 
Iselin, New Jersey 08830 
ATTENTION: Elsa Keller, IP Department 
Telephone: (732) 321-3026 



Respectfully submitted, 

David D. Chung 
Registration No. 38,409 
Attorney for Applicants 
Tel: 650-694-5339 
Fax: 650-968-4517 
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